1. Field of the Invention
The present invention relates to techniques for encrypting and decrypting data. More specifically, the present invention relates to a method and an apparatus that manages secret keys in a manner that facilitates making data permanently unreadable.
2. Related Art
Making data robustly available is an important and difficult problem, but sometimes it is equally important for the data to become reliably unrecoverable. One example is email. One might want a certain class of emails to be readable for only some finite amount of time, say two weeks. Even if the data is explicitly deleted, copies may remain on backup media, or may have been captured and stored in transit (e.g., at a router or mail transfer agent) or even be forensically recovered from disk.
There are some email systems that have a “self-destruct” feature. This is implemented purely in the mail reading client, and involves no cryptography. It just means that the copy of the email at the client is automatically deleted after reading (or perhaps merely marked as deleted). There are also commercial systems that allow setting policies, which state that email should be deleted automatically after some time. Again, this involves no cryptography, and copies on backup media would of course not go away.
Another approach is to only store the data in encrypted form, and then destroying it is a somewhat easier problem because we just need to delete the key. However, long-term user keys can, over time, be made available through compromise or coercion. It is possible for keys to be kept in tamper-resistant smart cards, in which case it would not be feasible to covertly discover the key. To delete the data, the user need only destroy the smart card. But it is expensive to require every user to have a smart card and every computer to have a smart card reader.
A more sophisticated system for managing secret keys was designed by a company called Disappearing, Inc. This system uses a special server whose job it is to create and destroy keys. We will refer to this server as an “ephemerizer”. Conceptually, the Disappearing, Inc. system worked as follows:                1. If Alice wishes to create an encrypted message for Bob, she contacts the ephemerizer, requesting a key and an expiration time.        2. The ephemerizer chooses a random secret key K, assigns a key identifier, IDK, tells Alice: (K, IDK), and remembers: (expiration time, K, IDK).        3. Alice encrypts the message M with K to obtain {M}K and sends to Bob: ({M} K, IDK)        4. When Bob wishes to decrypt the message, he sends the ephemerizer: IDK.        5. The ephemerizer replies with K, and then Bob can decrypt the message.        6. When the expiration time is reached, the ephemerizer forgets K.        
To be secure, Alice and Bob communicate with the ephemerizer via some protected channel such as Secure Sockets Layer (SSL), in which they authenticate that they are indeed talking to the ephemerizer, and such that the messages between the ephemerizer and a client are encrypted.
A nice property of the Disappearing, Inc. system is that the ephemerizer could be built so it does not see messages. However, the ephemerizer must create and store a key for every ephemerally created message. This can involve storing a large amount of data if the system is used for encryption of many messages.
Hence, what is needed is a method and an apparatus that manages secret keys in a manner that facilitates making data disappear without the above-described problems.